Пресса о страховании, страховых компаниях и страховом рынке

ComNews.ru, 23 сентября 2019 г.

Проектные фабрики меняют бизнес телеком-операторов и банков

579 просмотров

В цифровую эпоху скорость вывода услуги на рынок стала важным конкурентным преимуществом. Классические методики разработки часто не устраивают бизнес, но так ли хороши гибкие подходы?

Если в отрасли сильна конкуренция, то одним из способов быть «на передовой» может стать быстрый вывод продуктов и услуг на рынок и их оперативная корректировка. Неплохо себя зарекомендовавший в различных сферах классический водопадный подход не обеспечивает нужной скорости, поэтому высокотехнологичные компании активно осваивают новые подходы к созданию и выводу продуктов и услуг на рынок. Одним из них являются гибкие методики разработки. Результаты их использования далеко не всегда соответствуют ожиданиям. Попробуем разобраться, почему так происходит и как избежать проблем.

Кому это нужно?

Если говорить о конкретных отраслях российского рынка, проблема касается в основном банков, страховых компаний, телеком-операторов и онлайн ритейлеров. Помимо традиционных сервисов они предлагают клиентам огромное количество собственных или партнерских услуг, превращаясь в своеобразные цифровые маркетплейсы. Сюда можно отнести и классический ритейл, запускающий торговлю и доставку через интернет, а также любую компанию с развитой ИТ-инфраструктурой, если она работает на массовые сегменты рынка — в основном это B2C и SMB.

У такого бизнеса часто возникает потребность максимально быстро пройти путь от идеи услуги до ее практической реализации и быстрой доработки после тестирования. Сократив time to market, скажем, с 1 года до 4-6 месяцев, можно получить серьезное преимущество перед конкурентами: если идея зацепила рынок, фора в несколько месяцев будет критичной. В условиях высокой неопределенности приходится проверять предлагаемые маркетологами гипотезы, связанные с увеличением потребительской активности и спроса. Каждая такая инициатива требует доработки ИТ-систем и сайта, проведения маркетинговых мероприятий и акций, доработки клиентских договоров, обучения торгового персонала.

Так ли плох классический подход?

Компании обычно работают в условиях ограниченности ресурсов, им приходится выводить на рынок достаточно сложные и толком не формализованные услуги. Классическое проектное управление в этом случае загружает ресурсы на 100% и гарантирует выполнение запланированных работ, но не позволяет оперативно оценивать реакцию рынка на новые предложения, чтобы отбросить нежизнеспособные идеи и быстро выполнить доработку продуктивных. Здесь бизнес работает в условиях высокой неопределенности и, если ваш «шаг» занимает полугодие или год, конкуренты успеют за это время вывести новую услугу на рынок, доработать её и снять «сливки» с новой рыночной ниши.

Водопадная методика оперирует длинными циклами и не предназначена для оперативной корректировки проекта на основании регулярно получаемой обратной связи. Сначала аналитики определяют и описывают все требования бизнеса, затем программисты, после чего продукт поступает на тестирование и доводится до ума. Бета-версия решения, в лучшем случае, появляется через полгода. За это время может оказаться, что аналитики неполностью смогли оценить бизнес-требования и их приоритетность, потребности рынка изменились, а в ходе дальнейших фаз проекта в исходный замысел были внесены искажения. Начинается вторая итерация, корректируются требования, систему изменяют и тестируют — выход рабочей версии может отложиться еще на год, за это время рынок может измениться, а проект станет неактуальным.

С другой стороны, помимо тактических, у компании есть и стратегические цели, поэтому совсем от водопадной методологии отказаться невозможно. Какие-то глобальные этапы все равно сохранятся на верхних уровнях, но для решения оперативных тактических задач придется внедрять гибкие методики. Они позволяют быстро изучить требования бизнеса и в течение, скажем, месяца сделать работающий прототип. Он будет не вполне функциональным, но все связанные с непониманием между группами сотрудников и потенциальными потребителями ошибки не будут усугублены длительным циклом разработки. Их можно достаточно быстро исправить и протестировать на каком-то ограниченной группе пользователей. После этого услугу запускают на более широкую аудиторию и если идея удачна, тут же начинать ее расширять и дорабатывать, чтобы получить приток потребителей.

Что такое проектная фабрика?

О своеобразных фабриках решений, продуктов или проектов (терминология еще не устоялась) в отрасли заговорили лет пять назад. Если коротко, такая фабрика предполагает два уровня планирования: на стратегическом используется классический водопад с длительным циклом на, 6, 12 или более месяцев, а команды на более низком уровне применяют либо водопад, либо различные гибкие методики в зависимости от специфики решаемых ими задач.

Первая проблема здесь: как с точки зрения методологии правильно спланировать разные потоки работ, которые по-разному выполняются и оцениваются по различным KPI. Вторая трудность — с помощью каких средств автоматизации обеспечить устойчивость внедренных процессов и минимизировать управленческие расходы на их поддержание. В классическом управлении проектами существует большой портфель инструментов для автоматизации, для гибких методологий также существует свой набор инструментов. А что использовать в случае совместного использования различных проектных методологий?

Достаточно часто оказывается, что такой «палочкой-выручалочкой» могут стать решения на платформе Atlassian, которые «из коробки» поддерживают гибкие методологии, а с помощью дополнительных плагинов, например Structure, и классическое водопадное планирование, и управление.

Почему не работают гибкие методики?

Проблем с выбором инструментов нет, главная сложность заключается в другом: сейчас многие компании самостоятельно переходят на гибкие методологии и даже считают, будто у них все получилось, но на самом деле это не так. По непонятной причине эджайл-инструменты работают плохо. В реальности оказывается, что гибкая в компании только терминология, а фактические процессы соответствуют водопадной методике. В этом случае в первую очередь нужно понять, стоит ли вообще связываться с гибкими методиками или лучше использовать классическую с соответствующими средствами планирования.

Если у бизнеса есть потребность в быстром выводе услуг на рынок и оперативной обратной связи, стоит попробовать работать более короткими циклами. Чаще всего оказывается, что в рамках отлаженных процессов это невозможно, и тогда приходится менять процессы. При этом важно понимать, что бизнес-заказчикам нужно оперативно работать с ИТ-департаментом не раз в полгода, а практически каждый день — обычно речь идет о 5-8 часах в неделю. Поскольку появляется возможность быстрого внедрения новых предложений и корректировки старых, бизнес должен быть готов оперативно отрабатывать обратную связь. ИТ-департамент обычно не против, основным тормозом прогресса становится руководство компании. Изменение подхода к доставке стоимости потребует от него кардинальной перестройки стратегии взаимодействия с ИТ.

Итоги

Решение о перестройке бизнес-процессов компании не может быть внешним. Если надо просто перевести их на другую методику, для этого достаточно пригласить консалтинговой компанию. Если перевод процессов нужно еще закрепить внедрением системы автоматизации — потребуется системный интегратор с опытом разработки подобных решений. Кто-то проводит внедрение своими силами, кто-то приглашает сторонних специалистов, но сейчас проектные фабрики — это очень перспективный рынок. Многие компании либо думают о них, либо уже находятся на этапе трансформации.

Андрей ФАДЕЕВ,
руководитель направления Atlassian компании «Системный софт»

Ваше мнение об этом материале:

— Ваше имя
— Ваш email
— Тема

Ваш отзыв (заполняется обязательно):

Укажите код на картинке слева:

Установите трансляцию заголовков прессы на своем сайте

 Подробнее »

Получить код для трансляции заголовков прессы »